8.1 反馈信息的必要性

JRockit成为业界领先的JVM，离不开用户的大力协助。JRockit致力于提供服务器端应用程序的性能和扩展性，最具相关性的反馈信息往往来自于部署了大量服务器的用户，例如金融行业的用户。JRockit Runtime Analyzer，或简称JRA，最初是为了收集JRockit的性能信息而进行开发。

其实，用户并不太愿意将其应用程序相关的敏感数据发给JRockit开发团队，当然更不会让JRockit开发团队在其生产环境中做性能分析，因为某些用户应用程序每周所处理的资金流水可能高达每周数十亿美元。故而，就需要有一种工具来帮助收集JRockit和其中的应用程序的的运行情况，这样既有助于改进JRockit，还可以发现用户应用程序有哪些异常行为。当然，要想实现这个工具会面临一些挑战。要想准确的找到系统性能瓶颈，就需要准确测量系统各个参数，此外，还要尽可能降低工具的执行开销。如果工具本身会产生较大的执行开销，也就无法获知系统的真实运行情况了，用户也肯定不会在生产环境中使用这个工具。

作为一款记录应用程序运行时信息的工具，JRA使用非常方便，而且能够提供足够多的信息来优化JRockit。今天，作为问题诊断和性能调优工具，JRA已经获得用户的广泛赞誉。

起初，JRA使用XML文档来记录运行时信息，这样既方便开发人员进行调试，也可以让用户知晓具体有哪些信息被记录了下来。后来，JRockit的开发人员调整了记录信息的内容，加入了与系统延迟相关的数据，于是乎，JRA记录的数据就被分成了两部分，分别是具备可读性的XML文件，和记录了延迟事件的二进制数据。在记录运行时信息的过程中，延迟信息存储在JRockit的内存缓冲区中，同时，为了避免引入额外的延迟和性能损耗，延迟信息是直接从内存缓冲区直接写入到磁盘的。

因此，JRA生成的文件有两种类型，.jra和 .jfr，分别对应于JRockit R28之前和之后的不同版本。在JRockit R28版本之前，JRA输出的文件中主要是没有关联数据模型的XML文档，而到了R28版本之后，记录文件中保存了关联着事件模型的二进制数据，更便于使用分析工具进行性能分析。

若想打开JFR的记录文件，必须要使用JRockit Mission Control 3.x版本；而若要打开Flight Recorder的记录文件，则至少要使用JRockit Mission Control 4.0以上的版本才行。

译者注，俺觉着这里应该是"想打开JRA的记录文件"。

8.1.1 记录

通过以下几种方可以控制开启/结束对运行时信息的记录：

• 使用JRCMD命令行工具。更多有关JRCMD的内容，请参见第11章。
• 使用JVM命令行参数。这方面更多的内容，请参见JRockit文档中有关-XXjra参数的描述。
• 使用JRockit Mission Control套件中的JRA图形化工具。

当然，最简单的方法还是在JRockit Mission Control GUI中通过JRA/JFR的提示创建完成对记录信息的控制。在JVM浏览器展示区中选择目标JVM后，点击工具栏中的JRA按钮即可，或者在上下文菜单中开启JRA记录。通常情况下，使用预定义的配置即可，如有特殊需要的话，可以性调整。在JRockit Mission Control 3.x版本中，预定义的配置如下图所示：

• Full Recording: 标准用例，默认情况下会记录大部分相关数据，时长为5分钟。
• Minimal Overhead Recording： 该模板主要应用于对系统延迟非常敏感的应用程序，例如，它不会记录堆的统计数据，因为这些数据会引发额外的垃圾回收操作。
• Real Time Recording： 当系统运行在JRockit Real Time上，并且需要处理系统延迟方面的问题时，该模板会非常有用。该模板提供了额外的文本输入框来设置系统延迟的阈值（后续会对此值做详细介绍），在此种类型下，默认的延迟阈值会从20ms降低为5ms，而且记录时间也比默认值短。
• Classic Recording： 值得注意的是，在此种类型下，记录信息中并不包含任何与系统延迟相关的数据。如果JRockit是R27.3之前的版本，又或者对延迟数据不感兴趣的话，可以使用此种类型。

点击 Show advanced options复选框，可以对模板做定制化配置。一般来说，这并非必须。下面对一些选项进行简单介绍：

• Enable GC sampling: 该选项控制是否记录于GC相关的信息。如果明确了对GC信息不感兴趣的话，关闭之即可。该选项默认打开。
• Enable method sampling: 该选项用于控制是否启用方法采样。方法采样是通过JRockit的代码优化组件的采样数据实现的。如果应用程序对系统性能有较高的要求，那么最好谨慎设置方法采样的周期。
• Enable native sampling: 该选项用于控制是否在做方法采样时采样执行本地代码所花费的时间。大部分情况下，只有JRockit开发人员和支持人员会关心此项数据，因此默认情况下不开启此选项。
• Hardware method sampling: 在某些硬件架构上，CPU中包含了特殊的硬件计数器，在此基础上，JRockit可以更好的完成方法采样的工作。因此，只有在这些硬件架构上，该选项才真正有用。
• Stack traces: 开启该选项不仅可以从方法采样中获知采样次数，还可以得到调用栈信息。如果关闭此选项的话，在热点方法列表中，就不会包含采样点的调用信息了。
• Trace depth: 该选项指定了获取调用栈信息时所要进入的深度。在JRockit Mission Control 4.0版本之前，该选项的默认值是16，对于那些使用了大型编程框架的应用程序来说，这个设定值太小，完全没有意义。一般来说，设定在30以上，才能有所帮助。
• Method sample interval: 该选项指定了两次线程采样之间的时间间隔。在两次采样的时间间隔之内，JRockit会以Round-Robin的方法暂停一部分线程的执行，而采样只会发生在正在运行的线程上。这样就可以找出应用程序的计算量主要发生在哪里。更多详细内容请参见8.2.3.2节.
• Thread dumps: 开启该选项后，JRockit会在记录开始和结束时记录线程栈的调用信息。如果设置了线程转储的时间间隔，则在记录的过程中，还会每隔一段时间就做一次线程转储。
• Thread dump interval: 该选项用于控制两次线程转储的时间间隔。
• Latencies: 开启该选项后，JRA会记录一些延迟相关的信息。更多有关延迟的内容，请参见8.2.5节
• Latency threshold: 在设置该选项值后，JRA只会记录延迟时间大于该阈值的时间。一般情况下，会将该选项值设置为20ms，19ms也不会有太大问题。但如果设置太小，就会产生较大的运行时开销，而且产生的日质量也会大的惊人。
• Enable CPU sampling: 开启该选项后，JRockit会记录下CPU负载信息。
• Heap statistics: 开启该选项后，JRockit会在记录开始和结束时各做一次堆内存分析。由于执行堆内存分析需要额外执行一次垃圾回收来收集相关信息，因此在需要低执行开销的模板中是禁用该选项的。
• Delay before starting a recording: 使用该选项可以使JRA在应用程序运行一段时间后再开始记录。延迟时间的设定通常以分钟为单位，用户也可以自行选择相应的时间单位。

在执行记录之前，要先指定记录文件会存放在哪里。当JRA开始记录后，会打开一个编辑器显示相关的配置选项。在记录结束后，会显示记录的具体内容。